1. Technical Field
The present invention relates to a system and method that prevents a replay attack. More particularly, the present invention relates to a system and method that prevents a replay attack in an encrypted file system.
2. Description of the Related Art
Encrypted file systems allows files stored on nonvolatile storage, such as a hard drive, to be encrypted in order to protect confidential and sensitive data and prevent it from being stolen by a malevolent user, such as a hacker. In order to protect data in an encrypted file system, one or more encryption keys are used to encrypt and decrypt the data. In addition, some encrypted file systems use a digital hash to further protect encrypted file blocks. A hash function is executed against the encrypted file blocks resulting in a hash value for each of the blocks. Each hash value serves as a digital “fingerprint” of its corresponding encrypted file block. The encrypted file system executes the hash function when storing data and stores the data hash blocks along with the encrypted file data blocks. If a malevolent user replaces an encrypted file data block, the stored hash value will no longer match the new data in the encrypted file data block, resulting in an error.
For example, assume that a file block of “$25.00” has a corresponding hash value of “ABC123” and a file block of “$100.00” has a corresponding hash value of “XYZ456.” If a malevolent user attempts to increase his balance of “$25.00” by writing a “$100.00” to the data block, the hash of the new data block (“$100.00”) value would now be “XYZ456” and would no longer match the stored hash value of “ABC123.” This would result in an error that would notify the system administrator that someone altered the encrypted file block, and appropriate action could be taken (e.g., disabling the user's account because the balance was improperly altered).
A challenge of using encrypted file systems with data block hashes, however, is that a malevolent user could copy both the encrypted file block and the corresponding hash value to a different location. Then, after the encrypted file block and the corresponding hash value have been altered by legitimate processes, the malevolent user could overwrite the encrypted data block and the data block hash with the copied data. Using the example from above, the user's original account balance is “$100.00” and the stored hash value is “XYZ456.” Before using the service tied to the account balance, the malevolent user copies both the encrypted data block and the stored hash value (“$100.00” and “XYZ456”) to a separate location. After using the service, assume that the account balance is lowered to “$25.00” with a corresponding hash value of “ABC123.” Now, the malevolent user overwrites both the encrypted data block containing the account balance as well as the corresponding hash value with the data previously copied to the separate location (“$100.00” and “XYZ456,” respectively). Now, because “XYZ456” is the correct hash value for the encrypted data block containing the $100.00 account balance, an error will not occur when the overwritten encrypted data block is next read. In this manner, the malevolent user can repeatedly replenish the money in his account without ever paying for it.